Virtually all software used in enterprises today has the same goal: supporting business processes. Some processes are entirely automated, relying solely on communication among applications. Others—probably the majority—also rely on people to initiate the process, approve documents the process uses, resolve any exceptional situations that arise, and more. In either case, it's often possible to specify a discrete series of steps known as a workflow that describes the activities of the people and software involved in the process. Once this workflow has been defined, an application can be built around that definition to support the business process.
One example of a workflow in use is a workflow-based application for insurance companies. FIG. 1 illustrates a simple example of a workflow 100 for an application for an automobile insurance policy. The process begins when a submitter 110 sends in an application. This submitter might be an employee in a call center, an insurance agent in the field, or even a customer directly submitting an application over the Internet. However it's done, the arrival of a new application creates a new instance of this workflow 100. The workflow 100 begins by checking the information supplied in the request against this company's rules for issuing policies 115. If the applicant fails to meet the company's underwriting criteria, he or she is rejected 120. Otherwise, the workflow 100 requests the applicant's credit 125 history from an external credit service 130. A satisfactory credit score results in immediate acceptance 135, but high-risk applicants with bad credit histories require a manager's approval 140. If this approval is granted, the applicant is accepted 145. If not, the applicant is rejected 150.
To model this and other business processes, a workflow can include a number of activities that corresponds to different steps of the business process. At each of the activities, an action (e.g., determining whether an applicant meets a specific criteria) can be taken. Clearly then, an important part of an automated workflow technology is on how decisions are made in the workflow. And usually, a rules engine is responsible for evaluating rules utilized in a workflow.
In workflow development software, it is important that the software is able to offer a workflow framework to developers that is capable of supporting diverse applications. However, under conventional approaches, workflow software products and rules engines do not allow for a developer to define custom expressions within the workflow. Instead, the developer must either be content with the “out-of-the-box” expressions packaged with the rules engine, or the developer must define a method that gets called within the workflow. Unfortunately, both of these options can be inadequate. First, out-of-the-box expressions simply may not be tailored enough towards a specific problem that a developer is seeking to solve. Secondly, traditional methods do not participate in the workflow environment the same as rules do. For instance, rules and their corresponding expressions often participate in complex validation schemes that traditional methods do not. Furthermore, traditional methods do not lend themselves as well to forward chaining mechanisms as rules do.